Multiprotocol Label Switching (MPLS) has gained popularity as a method for efficient transportation of data packets over connectionless networks, such as Internet Protocol (IP) networks. MPLS is described in detail by Rosen et al., in Request for Comments (RFC) 3031 of the Internet Engineering Task Force (IETF), entitled “Multiprotocol Label Switching Architecture” (January, 2001), which is incorporated herein by reference. MPLS is also described by Andersson et al., in IETF RFC 3036 entitled “Label Distribution Protocol Specification” (January, 2001), which is incorporated herein by reference.
In MPLS, each packet is assigned to a Forwarding Equivalence Class (FEC) when it enters the network, depending on its destination address. The packet receives a label, referred to as an “MPLS label” identifying the FEC to which it belongs. All packets in a given FEC are passed through the network over the same path by label-switching routers (LSRs). The flow of packets along a label-switched path (LSP) under MPLS is completely specified by the label applied at the ingress node of the path. Therefore, an LSP can be viewed as a tunnel through the network, and is commonly referred to as an “MPLS tunnel.”
MPLS defines a label distribution protocol (LDP) by which one LSR informs another of the meaning of labels used to forward traffic between and through them. An extension of LDP for setting up constraint-based label switched paths (CR-LSPs) is referred to as CR-LDP and is defined by Jamoussi et al., in IETF RFC 3212 entitled “Constraint-Based LSP Setup using LDP” (January, 2002), which is incorporated herein by reference. CR-LDP provides support for constraint-based routing of traffic across the routed network. LSPs can be set-up based on explicit route constraints, quality of service (QoS) constraints and other constraints.
Another protocol used for setting up MPLS tunnels is RSVP-TE, which is described by Awduche et al., in IETF RFC 3209 entitled “RSVP-TE: Extensions to RSVP for LSP Tunnels” (December, 2001), which is incorporated herein by reference. RSVP-TE extends the well-known Resource Reservation Protocol (RSVP), allowing the establishment of explicitly-routed LSPs using RSVP as a signaling protocol. RSVP itself is described by Braden et al., in IETF RFC 2205 entitled “Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification” (September, 1997), which is incorporated herein by reference.
The RSVP-TE protocol defines a shared explicit (SE) reservation style that enables some bandwidth sharing. The SE style allows a receiver to explicitly specify the senders to be included in a reservation message. A single reservation is made on a link for all the senders listed.
In some applications, network elements allocate resources such as bandwidth to the services they provide. For example, the IETF has proposed the Integrated Services (IntServ) protocol architecture as a framework for allocating different levels of QoS to different services. IntServ is described by Braden et al., in IETF RFC 1633 entitled “Integrated Services in the Internet Architecture: an Overview” (June, 1994), which is incorporated herein by reference.